CNA를 가능하게 하는 기술

이전글(클라우드용 어플리케이션은 뭐가 다를까?)에서 CNA(Cloud Native Application)의 필요성과 특성에 대해서 알아보았다.

이번에는 이런 CNA를 가능하게 하기 위한 기술에 대해서 알아보자.
CNA 를 구현하기 위해서는 아래 그림과 같은 6가지의 기술이 필요하다.

• Microservices

이름에서 알 수 있듯이 기능별로 잘게 쪼개서 서비스를 개발하는 것이다.
이런 구조를 MSA(Micro Service Architecture)라고 부른다.
MSA의 반대는 모노리틱 아키텍쳐(Monolithic Architecture)이다.

모노리틱 아키텍쳐는 모든 기능을 하나의 덩어리고 만드는 것이다.
그래서 모노리틱 아키텍쳐로 개발하면 최적의 효율성을 보장할 수는 있지만 하나의 기능에서 발생한 문제가 전체 시스템에 영향을 주게된다.
이때문에 단순한 구조의 어플리케이션에는 적당한 아키텍쳐이지만 복잡한 기능을 가지고 있는 어플리케이션에는 안정성을 떨어뜨리는 구조이다.
반면 MSA는 기능별로 서비스를 분리하여 한 서비스의 오류가 다른 서비스에 영향을 주는 것을 막는다.
대신에 각 서비스간 데이터 통신량이 늘어나서 리소스가 더 많이 소모되고, 공유되는 데이터의 정합성을 맞추기 위한 추가적인 코드 개발이 필요하다는 단점이 있다.

• 12-Factors App

12-Factors App 의 정의에 대해서는 12factor.net 사이트의 머릿말에 다음과 같이 정의되어 있다.

Twelve-Factor app은 아래 특징을 가진 SaaS 앱을 만들기 위한 방법론이다. 

• 설정 자동화를 위한 절차(declarative) 를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.
• OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화 한다.
• 최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.
• 개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
• 툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있다.

12개의 Factor 에 대한 자세한 내용은 12factor.net 사이트의 내용을 참조하기 바란다.

• Multi-tenancy

멀티 테넌시(Multi-tenancy)란 여러 사용자(거주자)를 갖는 아키텍쳐이다.
집에 비유하자면 아파트에 비유할 수 있다.

말이 어려워서 그렇지 우리는 이미 이런 서비스 환경에 익숙해져 있다.
예를 들면 웹메일 서비스의 경우를 보자.
웹메일 서비스는 하나의 웹 어플리케이션이지만 여러 사용자가 각자의 환경속에서 사용하고 있다.
각자의 메일 보관함은 철저하게 분리되어 타인의 메일을 볼 수도 없으며 자신만의 화면이나 메일함들을 생성하여 개인화(Personalized)된 UI를 사용할 수도 있다.
이처럼 하나의 서비스내에서 사용자별로 저장공간과 설정내용 등을 독립적으로 관리한다.
이런 아키텍쳐의 장점은 하나의 시스템을 여러 사용자가 공유하는 구조이기 때문에 비용을 절감할 수 있다.
또한 겉으로는 사용자별로 다르게 보이지만 내부적으로는 하나의 스키마(Schema)를 가지고 있기 때문에 데이터 통합이 쉽다는 것도 장점이다.
하지만 사용자별로 다르게 보여주기 위해서는 서비스를 정교하게 개발해야하고, 만약 버그 발생시 시스템 전체에 영향을 미칠 수 있다는 단점도 존재한다.
게다가 데이터가 통합 관리되기 때문에 보안에도 취약한 구조이다.

• Container

컨테이너 기술과 비교되는 것이 가상화(Virtualization) 기술이다.
이 둘은 겉으로 보기에는 비슷한 면이 있어서 항상 비교가 되곤 한다.
하지만 엄밀히 말하면 컨테이너 기술과 가상화 기술은 전혀 다르다.

가상화 기술은 OS를 통째로 가상화한 것이고, 컨테이너 기술은 OS 위에서 환경을 격리(Isolation) 시킨 것이다.
그래서 OS 가상화처럼 인스턴스 생성시 부팅이라는 과정이 존재하지 않고, OS 자원을 공유하기 때문에 속도도 빠르다.
컨테이너 기술은 각각의 운영환경을 컨테이너라는 곳이 보관하여 서로 격리 시키는 기술이다.
리눅스에는 기본 내장되어 있는 기능이고, 향후 윈도우(Windows)  계열의 OS 도 지원할 예정인 기술이다.

• API

API(Application Programming Interface) 는 프로그램간의 인터페이스 기술이다.
하나의 프로그램이 사용자(User)와 상호작용(Communication)하기 위해서는 UI(User Interface)가 필요하다.
마찬가지로 서로 다른 어플리케이션이 상호작용을 하기 위해서는 API가 필요하다.
API는 사전에 서로 약속된 규칙에 따라 서비스를 요청(Request)하고 응답(Response)하는 구조를 갖는다.
최근에는 REST 형식의 API가 주로 개발되고 있으며 데이터 타입도 JSON 포맷을 주로 사용하여 개발되고 있다.

초기의 API는 패킷(Packet) 형태로 정의되었고, 데이터는 바이너리(Binary) 형태로 개발되었다.
패킷형태의 API는 개발자에 의해서 패킷의 구조가 정의되었다.
그러다 보니 패킷의 구조가 모두 제각각이여서 API 이용에 많은 학습이 필요했었다.
또한 데이터 형태도 바이너리여서 패킷정의 문서가 없으면 내용을 알 수가 없었다.
그래서 나타난 것이 SOAP(Simple Object Access Protocol)이다.
SOAP 은 패킷의 형태를 표준화하기 위해서 등장하였고, 객체(Object)를 직렬화(Serialize)해서 전송할 수 있었다.
이는 패킷형태의 프로토콜에서는 생성하기 어려웠던 계층적인 데이터의 표현도 가능하게 되었다는 것을 의미한다.
또한 XML 포맷으로 SOAP을 정의하는 WSDL을 배포하여 프로토콜 공유도 한층 쉬워졌다.
하지만 다른 언어간 연동시에 데이터가 깨지는 문제들이 발생하여 개발에 많은 노력이 들어가야하는 단점들이 발생하게 되었다.
REST API 는 웹 프로토콜을 사용하여 플랫폼, 개발언어, 디바이스 종류에 상관없이 연동이 쉽게 이루어 질 수 있었고, JSON 포맷 사용으로 데이터의 가독성이 높아졌다.
JSON 포맷은 XML에 비해 경량화(Compact)된 사이즈를 제공하고 있어서 최근에 가장 많이 개발되고 있는 API 형태이다.

• PaaS

CNA는 SaaS 모델용 어플리케이션 이다. 따라서 PaaS 기술의 기반위에서 동작한다.
PaaS 관련된 내용은 "클라우드 컴퓨팅 이해하기"를 참조하기 바란다.

Read More

클라우드용 어플리케이션은 뭐가 다를까?

이전글(클라우드 컴퓨팅 이해하기)에서 클라우드 컴퓨팅의 개념을 이해해보았다.

그렇다면 몇가지 의문이 생길 것이다.
SaaS 모델로 클라우드 컴퓨팅이 발전하긴 할텐데 그게 말처럼 쉬운 것일까?
가상화(Virtualization) 기술이 발전하면서 IaaS 에서 PaaS 로는 발전할 수 있었다지만 PaaS에서 SaaS 로 발전하려면 또 어떤 기술이 필요할까?

이런 궁금증을 해결하려면 먼저 클라우드 네이티브 어플리케이션(Cloud Native Application)을 이해해야 한다.
아래 그림은 어플리케이션의 유형과 발전단계를 표현한 그림이다.

• Native Application

PC(Personal Computer) 의 도입으로 모든 프로그램은 PC 에서 실행되어야 했었다.
그래서 처음에 만들어진 어플리케이션(Application)은 돌아갈 PC 환경에 맞도록 패키징(Packaging) 되어 배포되었다.
그러다보니 동일은 어플리케이션도 Window용 Linux용으로 다르게 패키징 되었고, 같은 Window용 어플리케이션도 Window7, Window10 등으로 모두 다르게 패키징되어 배포되었다.
이렇게 패키징되어 배포되었던 어플리케이션을 Native Application(네이티브 어플리케이션)이라고 한다.

• Web Application

PC 환경에 인터넷이 결합하면서 나타난 것이 웹 어플리케이션(Web Application)이다.
웹 어플리케이션은 원격에 있는 서버(Server)에서 어플리케이션이 돌아가고, PC는 인터넷을 통해 서버로부터 정해진 서비스를 제공받는 형태이다.
그래서 PC 의 환경에 따라 어플리케이션을 따로 배포할 필요가 없고, 어플리케이션의 업그레이드도 손쉬운 장점이 있다.
하지만 인터넷이 안 될경우 사용할 수 없고, 인터넷 속도가 느려질 경우 실행 속도가 느려진다는 단점도 있다.
그리고 어플리케이션 사용자는 서버의 서비스를 일방적으로 받는 경우가 많아서 네이티브 어플리케이션(Native Application)에 비해 수동적인 면이 많다.

• Cloud Native Application

클라우드 컴퓨팅 환경이 빠르게 발전하면서 등장한 형태가 클라우드 네이티브 어플리케이션(CNA)이다.
CNA는 SaaS 모델의 환경에서 동작하는 어플리케이션이다.
그래서 인터넷을 통해 서비스 되어진다는 점에서는 웹 어플리케이션과 유사하다.
하지만 CNA는 사용자 스스로 어플리케이션의 설치하고 서비스를 컨트롤(Control)할 수 있다는 점에서 큰 차이를 보인다.


위의 3가지 어플리케이션 유형이 거의 20년 주기로 컴퓨팅 환경의 변화에 맞춰서 새롭게 등장한 것을 볼 수 있다.
현재가 웹 어플리케이션에서 CNA로 변해가는 과정이라고 이해하면 될 것 같다.


이번에는 CNA의 등장배경을 사업(Business) 환경의 관점에서 알아보자.
현재의 사업 환경은 불확실성이 높은 환경이다.
이렇게 불확실성이 높아진 환경에서 사업을 성공으로 이끌기 위해 어플리케이션도 다음과 같은 요구사항을 충족시켜야 한다.

• Speed

신속한 서비스의 배포 및 회수는 비즈니스의 불확실성을 극복할 수 있는 유일한 해법이라고 할수 있다.
또한 잘못된 배포로 인한 손해도 새로운 버젼의 즉각적인 배포로 최소화 할 수 있다.

• Safety

하나의 서비스에서 발생된 장애가 다른 서비스에 전달되지 않아야 한다.
설령 장애가 발생했더라도 빠르게 복구되어 사용자들이 장애발생을 인지하지 못하도록 해야 한다.

• Scalability

서비스 사용량에 대한 과도한 예측으로 발생할 수 있는 자원낭비나 반대로 부족한 사용량 예측으로 인한 서비스 품질 저하등의 문제가 발생하지 않아야 한다.
이를 위해 서비스의 수평적인 확장은 물론 이를 동적으로 적용할 수 있어야 한다.

• Diversity

사용자들이 다양한 채널로 접근할 수 있도록 서비스가 제공 되어야 한다.
최대한 많은 사용자에게 서비스의 기회가 주어져야 한다.

위와 같은 비즈니스 요구사항을 충족하기 위해서 CNA 는 다음과 같은 특징들을 가지고 있어야 한다.

• Services

각각의 서비스는 서로 느슨하게 결합되어 있고, API 를 통해 실행되고 관리되어야 한다.

• Handling Failures

장애가 발생했을 경우 이를 제어할 수 있어야 한다.

• Horizontal Scalability

수평으로 확장이 가능하도록 설계되어야 한다.

• Asynchronous Processing

서비스 요청은 비동기적으로 처리되어야 하고, 큐(Queue)를 사용하여 기능들을 분리해야 한다.

• Stateless Model

모든 데이터는 어플리케이션 코드와 분리 되어야하고, 여러 사용자가 동시에 실행할 수 있어야한다.

• Minimize Human Intervention

사용자의 개입을 최소화 할 수 있도록 신속하고 반복적인 배포(Deploy)가 가능해야 한다.
장애가 발생할 경우 장애를 탐지하고, 손실된 인스턴스(Instance)는 제거한다.
그리고 새로운 노드를 빠르게 생성 할 수 있어야 한다.

Read More

클라우드 컴퓨팅 이해하기

클라우드 컴퓨팅이란 무엇일까?

간단하게 말하면 인터넷을 통해서 파일 저장소, 데이터베이스, 가상 서버, 네트워크, 소프트웨어 등의 컴퓨팅 환경을 제공하는 것을 말한다.
즉 서버 포함하여 개인 컴퓨터가 가지고 있거나 가질 수 있는 모든 기능을 인터넷을 통해서 서비스하는 것을 통칭하는 것이라고 생각하면 될 것 같다.

모든 것을 인터넷으로 서비스(Service)하기 위해서 클라우드 컴퓨팅은 다음과 같은 특성들을 가지고 있어야한다.

• Broad network access

다양한 사용자의 기기들이 인터넷을 통해서 서비스에 접속할 수 있어야한다.

• On-demand and Self-service

서버, 네트워크, 스토리지 같은 자원들은 사용자의 요청에 따라 언제라도 공급이 가능해야하고, 이를 사용자가 직접 제어할 수 있어야 한다.

• Resource pooling

제공되는 전체 자원은 여러 사용자들에 의해 공유 되고 재사용 되어야하고, 대신에 각각의 사용자 영역은 자원을 반납하기 전까지 독립적으로 유지되어야 한다.
이를 위해 가상화(Virtualization)와 멀티테넌트(Multi-tenant)를 구현해야한다.

• Rapid elasticity

제공되는 자원은 빠르고 탄력적(Rapid elasticity)으로 공급되어야한다.

• Measured service

사용자의 서비스 사용량은 정량적을 측정되어 사용자에게 전달되어야한다.



위와 같은 특성을 갖는 클라우드 컴퓨팅은 서비스 범위에 따라서 아래와 같이 구분하여 표현할 수 있다.

출처 : https://blogs.msdn.microsoft.com/eva/?p=1383

• Packaged Software

개인용 컴퓨터가 보급되면서 개인이 하드웨어 부터 소프트웨어에 이르기까지 모든 자원을 스스로 관리하는 모델이 나타나게 되었다.

소프트웨어는 패키징(Packaging)되어 공급되었고, 사용자들은 패키징된 소프트웨어를 자신의 컴퓨터에 설치해야만 사용할 수 있었다.

뿐만 아니라 인터넷을 사용하기 위해서는 통신서비스 업체에게 인터넷 서비스를 신청해야했고, 저장 용량이 부족하면 하드디스크(HDD)의 용량을 늘리는 작업들을 모두 직접해야만 했다.

사용자는 컴퓨터의 전문가 수준이 되어야만 했던 모델이다.

• IaaS(Infrastructure as a Service)

클라우드 컴퓨팅의 IaaS 모델은 인프라(Infrastructure) 자원은 서비스(Service)로 제공받고 나머지 부분에 대해서만 사용자가 관리하는 모델이다.

그래서 사용자는 인터넷 서비스 업체를 선정하거나 하드디스크(HDD)의 용량을 늘리는 작업을 직접 하는 것이 아니라 서비스로 제공받는다.

사용자가 할 일은 인터넷 속도와 하드디스크의 용량을 결정하여 서비스를 요청(Self-Service)하고 그에 대한 대가를 지불하면 된다.
초기 클라우드 컴퓨팅은 IaaS 모델로 서비스를 시작하였다.
현재 아마존(AWS)의 EC2와 S3 , 마이크로소프트(Microsoft)의 Azure, IBM 등이 모두 IaaS 모델의 서비스를 제공하고 있다.

• PaaS(Platform as a Service)

PaaS 모델은 IaaS 모델의 범위를 넘어서 O/S 와 미들웨어까지 서비스(Service) 형태로 제공하는 모델이다.
사용자는 하드웨어 리소스(H/W Resource)뿐만 아니라 O/S 와 그 위에서 동작하는 미들웨어까지 모두 서비스 요청으로 제공받을 수 있다.
결국 사용자는 어플리케이션 개발과 데이터 관리만 신경쓰면 되는 모델이다.
현재의 클라우드 컴퓨팅은 IaaS 모델 서비스를 확대하여 PaaS 로 나아가고 있다고 할 수 있다.
클라우드 컴퓨팅을 이끌고 있는 아마존(AWS)과 마이크로소프트의 Azure 가 모두 PaaS 모델의 서비스를 제공하고 있다.

• SaaS(Software as a Service)

SaaS 모델은 PaaS 모델의 범위를 더욱 확대하여 어플리케이션과 데이터 관리까지 모두 서비스 형태로 제공하는 모델이다.
사용자가 할 일은 비즈니스 모델(Business Model)을 개발하여 그에 맞는 서비스들을 선택하고 요청하는 일만 하게되는 모델이다.
현재의 클라우트 컴퓨팅 제공업체들이 아직까지는 SaaS 모델을 완벽하게 지원하고 있지는 않는다.


로컬(Local) 컴퓨팅 시대에서 클라우드 컴퓨팅 시대로 세상은 빠르게 변하고 있다.
클라우드 컴퓨팅도 IaaS 에서 PaaS 로 빠르게 발전하고 있다.
클라우드 컴퓨팅은 조만간 PaaS 에서 다시 SaaS 발전해 갈 것이다.

Read More